Existing software systems attempt to map business problems to high-level workflows by modeling the business problem. In general, the workflow process involves a series of tasks or actions, the order in which they must be performed, permissions defining who can perform them, and script that is executed for each action. Workflow may also be described in terms of states and events. A workflow engine, which may be a component of a software system that enables workflow, enforces the workflow definition and executes workflow actions.
The workflow engine has three main functions. First, it verifies whether a change is valid for the current workflow state. Second, it checks if the current user has permission to execute the workflow event. Third, if the event is valid and the user has permission to execute the event, the workflow engine permits execution. For example, in managing a series of tasks, such as those involved in publishing a news article, a series of work items must be performed. In this example, tasks include writing the article, editing the written article, reviewing the edited article, and publishing the edited article. A typical workflow engine may request that different service provider components (e.g., Write component, Edit component, Review component, and Publish component) perform these work items or tasks.
The workflow engine/component of a software system regularly communicates with other components (e.g., Write component, Edit Component, or the like) to monitor the states of the various work items. At the same time, these components may also monitor or checkpoint the states of these work items. Unfortunately, these components have no mechanism for keeping their persisted states consistent.
For example, the workflow engine may call different components to execute a number of work items during execution of a workflow. The workflow engine may send several messages to these components to determine the states of the work items. Each message that is sent invokes a messaging service provider component. Because the messaging component is required to maintain consistent and durable state with respect to the workflow, messages should not be sent out unless the workflow states can be successfully persisted.
Unfortunately, this type of vertically integrated software system design approach (i.e., execution of work items substantially upon arrival of data) has many shortcomings. For example, while one component is performing a particular task or work item, other components may not know the state of that particular work item (e.g., completed, executing, or abandoned). In addition, when there is a failure in executing one or more work items in a workflow to be performed, the workflow engine may be required to re-execute the entire workflow due to a lack of state knowledge.
Accordingly, improvements in workflow management for synchronizing runtime and application state of work items via a mechanism for batching of workflow transactions and for enabling the workflow engine, through batching of transactions, to delay execution of work items and to maintain consistency of persisted state of work items across communicating components are desired to address one or more of these and other disadvantages.